API endpoints provide a way for your organization to interact with i360 databases. This is a REST-ful API. To begin utilizing the endpoints, you need to have an i360 Org ID and user credentials associated with your Org and a basic understanding of how to craft HTTP requests. You can use tools such as Fiddler or Postman to begin using our endpoints.

Testing Endpoints

Calls made using i360 endpoints are against live data which is associated with your organization’s database. In the instance of a DELETE call, you will be deleting records in your database. It is our recommendation that all experimentation be done using our API sandbox. To request sandbox credentials please contact your i360 Account Representative.

If you are considering partnering with i360 please email our business development department for more information.

Consuming our API

We use the following definitions in our calls:

  • POST — Typically used to create records and return complex parameter sets.
  • PUT — Typically used to update records.
  • GET — Used to retrieve records.
  • DELETE — Used to remove records.


The HTTP verb you use when sending a request to the API is important. The API will reject requests which use the improper verb for a given endpoint. In general, the GET verb is used to obtain data from the API whereas the POST verb is used to send data to the API. There are some cases where an endpoint may allow either GET or POST actions to be used. In these cases it is up to the user to decide how they would like to utilize the endpoint; it is often best to use the POST endpoint since it is not limited by the length of a URL's querystring. For an example, see the Volunteers/Search endpoint.

Our Data

In using our endpoints it’s important to understand the different entities and how they interact with one another.

  • Contacts — Individual voter records in the database.
    • ContactID
  • Volunteers — Individuals supporting campaign efforts through activities with independent records in the database.
    • VolunteerID
  • Prospects — Contacts with favorable attributes for campaign recruiting efforts.
  • Users/Coordinators — Individuals that are staff members of the Organization.
  • Events
    • Assignments — Contact search, Staff and Volunteers working the event
    • Attendees — Event RSVP list
    • Metrics — Unique organizational metrics to record
    • Details — Supporting information about the event
    • Notes — Displays copy, author, and date/time stamp
  • Surveys — Scripts, templates, and caller IDs used for voter outreach methods.
  • Imports — Data uploads by batch.
  • Search — Individual parameters within the database available for query.
  • Emails — Adds email campaign statistics to Portal for Exact Target.


Most requests to API 2.0 are authenticated using OAuth 2.0 Bearer tokens. You must get a Bearer token before you can make authenticated requests.

Getting a Bearer Token

In order to get an OAuth 2.0 Bearer token, you must submit both a set of client credentials and a set of user credentials to the authentication endpoint, as follows:

  1. Prepare a POST request to /core/connect/token.
  2. Set the Authorization header to an ASCII+Base64-encoded string (as described below) in the format Basic {encoded token},
  3. Set the Content-Type header to application/x-www-form-urlencoded, and
  4. Include the following parameters in the body of the request:
    • grant_type - This should always be set to "password".
    • username - This is your username.
    • password - This is your password.
    • scope - This should always be set to "openid profile sample".
  5. Ensure that the payload is properly form-urlencoded, for example:

The encoding of the authorization header's token is standard HTTP basic authentication. To generate this token, do the following:

  1. use "roclient" as your client username and "secret" as the password,
  2. concatenate the username and password together with a colon between them ("username:password"),
  3. convert the result to ASCII bytes,
  4. encode the result to a Base64 string.

Using the Bearer Token

The response returned from the API is JSON-formatted and includes a property called access_token. Use this property to construct an Authorization header whose value is formatted as Bearer {access token}. This new authorization header should be used when sending subsequent requests to the API. The response also includes an expires_in property, which indicates how long (measured in seconds) the token will be valid for use. Currently the token expires every 6 minutes.


The following examples illustrate how to authenticate to the API using your language of choice.

Response Codes

The following HTTP response codes represent a subset of the possible responses which may be returned from the API. When possible, the message will include details specfic to your request. Should you receive a response code which is not listed here, please reference this complete list of HTTP response codes.

200 OK

The request completed successfully.

204 No Content

The request completed successfully but there is no content to return.

400 Bad Request

One or more of the provided parameters are invalid or the POST payload was not provided or could not be parsed.

401 Unauthorized

The request was not authorized; the authenticated user does not have permission to perform the requested operation or access the requested data, or you are attempting to access an organization to which you are not authorized.

403 Forbidden

The request is not allowed, regardless of the authenticated user's permissions.

404 Not Found

The requested resource does not exist. This could mean that the resource was already deleted or that it never existed.

405 Method Not Allowed

The request was submitted using the wrong HTTP verb (e.g. GET instead of POST).

500 Internal Server Error

An internal, unexpected error occurred while processing the request.

Contact Us

Please email our business development department with any questions or comments you may have regarding the Web API.